With the ability to mix processors, complex peripherals, and custom hardware and software on a single chip, full-system design and analysis demand a new methodology and set of tools. Today, high performance integrated circuit (“IC”) technologies combine ever-increasing computing power with complex integrated peripherals and large amounts of memory at decreasing costs. It comes as no surprise that the software content of these embedded systems grows exponentially. While the system development tool industry has overlooked this trend for years, most estimates place the software development cost at well over half the total development budget for a typical system. The bias to software in system-level design arises mostly from the migration from application-specific logic to application-specific code, driven mainly by the need to cut down product costs and time to market.
Short product life cycles and customization to niche markets force designers to reuse not only building blocks, but entire architectures as well. The architecture cost is often paramount, thus the prime goal is to achieve the right combination of processor, memory and glue logic for efficient manufacturing. Once this prime goal is achieved, the architecture is analyzed for appropriateness and efficiency to different applications or behaviors. The fitness of a new architecture to a variety of end-user applications determines its market size. Reused architectures (platforms) often constitute the basis for a cluster of products that may differ in details such as software features, regulatory standards, or language specialization. Every time new features are added to a reused architecture, the architecture performance needs to be re-analyzed to ensure it provides the right timing and support. Using efficient system development tools can significantly streamline this performance analysis procedure.
An important part of the design consists in fitting together the behavior (from the specifications) and the architectural blocks (from IP suppliers) in such way that the cost, power consumption, and timing of the system can be analyzed. For the hardware side, ASIC (Application-Specific Integrated Circuit) companies provide gate-level models and timing shells. For the software blocks, a similar characterization method is expected from system development tools.
When properly separated, the behavior and the architecture may co-evolve. As new requirements in the behavior call for changes in the architecture, architecture considerations (e.g., production cost) may lead to behavior modifications. Good system design practice keeps the specification as abstract as possible and allows independent mapping of behavior onto architecture. This is the essence of what has been termed function/architecture co-design.
Once mapped, the behavior can be annotated with estimated execution delays. The delays depend on the implementation type (hardware or software) and on the performance and inter-action of the architectural elements (e.g., IC technology, access to shared resources, etc. for hardware; clock rate, bus width, real-time scheduling and CPU sharing, etc. for software). These estimates should be accurate enough to help in making high level choices such as: deciding which behavior needs to be implemented in hardware and what can be done by software, how to architect the software in terms of threads, and what real-time operating system (“RTOS”) to use.
Embedded systems are a significant application area for system-level design. Embedded systems interact with the outside world. They may read sensors, control actuators, communicate with other systems, or interact with users. Timing accuracy of these tasks is very important. A system with tight timing constraints is a “real-time” system. Design specifications for such systems add time constraints to functional specifications. These constraints specify the minimum and maximum times that a component of the system can consume in completing a task. The design tools are expected to provide accurate timing simulations at early stages of system definition, to assist the designer. High-level performance estimation coupled with a fast co-simulation framework is a suitable solution to forestall performance problems in embedded system design.
Providing good timing information for the hardware/software co-simulator, at an early stage, before designing detailed hardware and software, is a very difficult problem, especially for the software side. Small architectural enhancements can rapidly obsolete a previously good software estimation technique. This goal was pursued through various methods, but none of these is suitable for the function/architecture co-design methodology. They generally target worst-case execution time analysis for a single program. These approaches are not suitable for embedded systems, which are composed of multiple tasks, accessing common resources, whose dynamic activation can significantly modify each others' execution paths.
Thus methods and systems are required to accurately evaluate the performance of a system at different levels of abstraction. The evaluation must be done dynamically, in a simulation environment, to capture run-time task interaction. Moreover, it should be fast enough to enable the exploration of several architectural mappings in search for the best implementation. Tunable models, where the designer can trade accuracy for speed, would do the best.